Protocol-Independent Multicast (PIM) is a family of multicast routing protocols for Internet Protocol (IP) networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the Internet. It is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other traditional routing protocols such as the Border Gateway Protocol (BGP).
There are four variants of PIM:
Of the four, PIM-SM has the widest deployment. PIM-SM is commonly used in IPTV systems for routing multicast streams between VLANs, Subnets or local area networks.
Contents |
Protocol Independent Multicast - Sparse-Mode (PIM-SM) is a protocol for efficiently routing Internet Protocol (IP) packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes (and their routers) will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group.
A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members.
Once the other routers which need to receive those group packets have subscribed, the RP will unsubscribe to that multicast group, unless it also needs to forward packets to another router or node. Additionally, the routers will use reverse-path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets.
Dense mode multicast is one mode that multicast can use to construct a tree for sending packets to the multicast subscribers. It is the opposite of sparse multicast.
The basic assumption behind dense mode is that the multicast packet stream has receivers at most locations. Sparse mode assumes relatively fewer receivers. Dense mode is ideal for groups where many of the nodes will subscribe to receive the multicast packets, so that most of the routers must receive and forward these packets (groups of a high density).
This difference shows up in the initial behavior and mechanisms of the two protocols. Dense Mode uses a fairly simple approach to handle IP multicast routing. The source initially broadcasts to every router, and thus every node. Then each node that does not wish to receive packets destined for that group will send a prune message to its router. Upon receiving a prune message, the router will modify its state so that it will not forward those packets out that interface. If every interface on a router is pruned, the router will also be pruned.
Additionally, the routers will use reverse-path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets.
PIM Dense Mode -- Overview
Protocol Independent Multicast has two modes, Dense Mode and Sparse Mode. This article only has space to cover the former. We'll get to PIM-SM in the next article. PIM Dense Mode (PIM-DM) uses a fairly simple approach to handle IP multicast routing. The basic assumption behind PIM-DM is that the multicast packet stream has receivers at most locations. An example of this might be a company presentation by the CEO or President of a company. By way of contrast, PIM Sparse Mode (PIM-SM) assumes relatively fewer receivers. An example would be the initial orientation video for new employees.
This difference shows up in the initial behavior and mechanisms of the two protocols. PIM-SM only sends multicasts when requested to do so. Whereas PIM-DM starts by flooding the multicast traffic, and then stopping it each link where it is not needed, using a Prune message. I think of the Prune message as one router telling another "we don't need that multicast over here right now".
In older Cisco IOS releases, PIM-DM would re-flood all the multicast traffic every 3 minutes. This is fine for low volume multicast, but not higher bandwidth multicast packet streams. More recent Cisco IOS versions support a new feature called PIM Dense Mode State Refresh, since 12.1(5)T. This feature uses a PIM state refresh messages to refresh the Prune state on outgoing interfaces. Another benefit is that topology changes are recognized more quickly. By default, the PIM state refresh messages are sent every 60 seconds.
Consider routers E and F in the above picture. When two PIM-DM routers connect to a LAN, they will see the multicast packets from each other. One should forward packets to the LAN, and the other not. They both send Assert messages. Best routing metric wins, with higher IP address as a tie-breaker. If they are using different routing protocols, a weighted routing metric scheme, somewhat like administrative distance, settles which router is to be the Forwarder (forwarding the multicast packets onto the LAN). The Forwarder may be silenced by a Prune from a downstream router with no receivers, if there are also no receivers on the LAN segment. Downstream routers may have to adjust their RPF neighbor, to reflect the winner of the Assert process.
To repeat that in full detail: when multicast traffic is received on a non-RPF interface, a Prune message is sent, provided the interface is point-to-point. These Prune messages are rate-limited, to make sure the volume of them (potentially, one per multicast received) doesn't cause further problems.
If the non-RPF interface is a LAN, an Assert message is sent. Non-Forwarder routers then send a Prune on their RPF interface if they don't need the multicast stream. Only one such Prune is sent, at the time of the transition to having no interfaces in the Outgoing Interface List (OILIST). The LAN Prune receiver delays acting on it for 3 seconds, so that if another LAN router still needs the multicast stream, it can send a PIM Join message to counteract (cancel) the Prune. ("Yo, that router doesn't need it, but I still do!")
Suppose a router has Pruned, and some time later a receiver requests the multicast stream with an IGMP message. The router then sends a Graft message. In effect, "hey, I need that multicast stream over here now".